Allow project search to be efficiently cancelled - #45300

I've benchmarked this branch against main (3 times each) and found the following:
cargo run -p project_benchmarks --profile release-fast -- -q vmx_l1d ../linux:
No regressions (both take about 1s to find first match and ~3.4s in total)
cargo run -p project_benchmarks --profile release-fast -- -q upstream_monomorphization ../rust
No regressions (both take about 20ms for first match and ~14s in total)
cargo run -p project_benchmarks --profile release-fast -- -q rust ../chromium
❗ Regressed; on main it takes 19ms to find the first match and 700ms in total, whereas on this branch it takes ~20ms (could be noise) and 1.3s in total. Somewhat consistently.

I'll update fs_benchmarks for this new scenario as well.

fs_benchmarks don't look great too with smol. With the following patch:

diff --git a/crates/fs_benchmarks/src/main.rs b/crates/fs_benchmarks/src/main.rs
index 12df32f076..330ca5760f 100644
--- a/crates/fs_benchmarks/src/main.rs
+++ b/crates/fs_benchmarks/src/main.rs
@@ -25,6 +25,15 @@ fn main() {
             } else {
                 println!("Took {elapsed:?} to query metadata");
             };
+
+            let timer = std::time::Instant::now();
+            let result = fs.open_read(path_to_read.as_ref()).await;
+            let elapsed = timer.elapsed();
+            if let Err(e) = result {
+                println!("Failed `open_sync` after {elapsed:?} with error `{e}`");
+            } else {
+                println!("Took {elapsed:?} to open");
+            };
             std::process::exit(0);
         })
         .detach();

It takes about 10 microseconds on main and ~100 microseconds on this branch. :/ I realize there's more to it (the interface exposed by read_sync on this branch lends itself more to cancellation), but still.. I'm actually surprised that does not regress our search further.

I'll run benches on Linux too. Maybe that'll shed some more light.

Closing this in favor of #45406 ; it differs in exposed interface (search uses a newtype instead of a tuple, which I find cleaner) and in not falling back to use of smol.
Thanks for raising the issue nonetheless, Max :)